A Method for On-Line Reorganization of a Database

Any database management system may need some type of reorganization. However, reorganization typically requires taking a database off line, which can be unacceptable for a very large or highly available (24-hour) database. A solution is to reorganize on line (concurrently with users' reading and writing of data in the database). This paper describes a method for performing one type of reorganization on line. The type of reorganization distributes free space evenly, removes overflow, and clusters data. The method for on-line reorganization copies data while arranging the data in the new copy in reorganized form. The method then applies the database log to bring the new copy up to date (to reflect users' writing of the old copy). The method maintains a table that maps between old and new record identifiers, to match log entries with data records in the new copy. w e define reolganization of a database as changing some aspect of the logical or physical arrangement of the database. In Reference 1, general issues in reorganization and types of reorganization are discussed, but in this paper we discuss one type of reorganization, along with the problem in reorganizing off line. The type of reorganization that this paper describes involves restoration of clustering. Clustering is the practice of storing records near one another if they meet certain criteria. One popular criterion is consecutive values in a column of the records. Clustering should reduce disk input and output for records that users often access together. We use the word user to refer to a person who develops or executes application programs that use the database. When users write data into the database, this writing can decrease the amount of clustering and thus degrade performance. Reorganization can restore clustering and performance. During most types of reorganization in a typical database , the area being reorganized is ofline or only partially available; users cannot write (and perhaps cannot even read) data in that area. However, a highly available database (a database that is to be fully available 24-hours-per-day, 7-days-per-week) should not go off-line for significant periods, of course. Applications that require high availability include those for reservations, finance (especially global finance), process control, hospitals, police, and armed forces. Even for less essential applications, many database administrators (people who supervise the use of a database) prefer 24-hour availability. The maximum tolerable period of unavailability is specific to the application. We asked customers of …